By pilotmatt - 7/31/2013 4:41:41 PM
Hi Tim
Not sure where to post this, so I'll put it here. Problem
I exported a flight log to GPX and imported it elsewhere. I noticed some very bizarre behaviour in the 'elsewhere' with particular respect to the aircraft's groundspeed. Cause
I traced the problem down the .flightlog files themselves. It wasn't hard to work out the format for the file. Regard the following: 26000,N513245.45 W0010622.95,191.4,93.8,324.5,239.3 29000,N513240.75 W0010623.55,177.1,95.4,361.9,301.7 30000,N513237.65 W0010622.85,172.0,95.0,378.3,344.2 31000,N513237.65 W0010622.85,167.1,96.6,395.7,344.2 31000,N513236.05 W0010622.20,167.1,96.6,413.4,367.2 32000,N513236.05 W0010622.20,167.1,96.9,413.4,367.2 34000,N513233.10 W0010620.25,153.2,97.0,448.5,424.5The first field is the number of milliseconds that have elapsed since the START= field at the file header. The rest is positional & velocity information. Consider lines 3-6. Between 30 and 31 seconds of flight, the aircraft apparently doesn't move (same position) despite the track and GS information suggesting differently. Then there is a second 31 second point logged at a different location, before a 32s point at the same location again. SolutionNot sure why this is occurring but clearly duplicate entries are creating issues not present when within the SD environment. I manually deleted the duplicate entries after manipulating a .flightlog in Excel and the results after exporting to GPX were better but not entirely fixed, probably because it isn't always the second row of duplicate data which is wrong. Also...
While investigating this, I realised why some of my flightlogs are from 2005 (!). The #START= field seems to use the system time of the recording unit to generate the timestamp. Why? We are using SD with GNSS navigation which is, in fundamental terms, a time-based navigation system!! Why not switch to using GPS time to generate the #START field? That way flightlogs will always show accurate dates & times even if, for example, I need to change the battery in my iPaq halfway through a days flying... #START=20050301110825
I fly something quick, but not time-machine quick... 
|
By ckurz7000 - 8/14/2013 4:47:23 PM
It seems to me that the data FORMAT is perfectly fine. It's how you derive the actual data that get's me scratching my head. The time information contained in the START item ought to be taken from the GNSS system; it is more accurate, automatically reflects zulu time and is resistant to erroneous clock settings. The elapsed milliseconds I would calculate as the difference in GNSS times of each fix and the START time. Anything else appears to me less robust and error prone. It might be for other reasons, though, that it was done that way. But one can always improve, right?
-- Chris.
|
|